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Enclosed is a marked-up copy of the mag tape controller req spec. The red marks are Metcalfe's 
and the blue ones are mine. Bob's comments are restricted to asking that the device be refered to 
as the Computer Magnetic Tape Controller (abreviated CMTC). 

My comments require more explanation. 

I believe that the allowable gap sizes and their meaning need to be carefully specified. I 
presume, but do not know, that reference (3) in section 3.0 specifies this. If so, the relevent 
numbers should be copied into the req spec. I do know that recovering from unusual tape 
errors associated with short blank spaces on the tape is tricky, difficult, and occasionally 
impossible. Section 5.5 appropriately emphasizes this point. 

It should be made much clearer that the firmware is an integral part of the controller and is 
to be designed concurrently with the controller rather than afterward by the same or a 
different party. This has implications in a number of places. For example, I don't think 
an intelligent design as described in 5.2 can be arrived at without considerable detailed 
design of the firmware. Otherwise only a guess can be made as to whether the constraints 
of section 6.4 can be met. 

In section 5.3, (5) Read Data, I don't believe that all of the length mismatch cases are 
described in detail. The document does say what to do if the memory buffer is shorter 
than the tape block length (5.5 (5)). It is not explicit in the opposite length mismatch case. 
Again, the immediate document is not explicit about how big of a blank area constitutes an 
end of block gap. In the case of the data buffer bigger than the tape block, the spec does 
not say if or where the software can recover the number of bytes actually transfered. 

The track-in-crror info should be specified as one of the status items to be returned in the 
10CB. I believe that we should specify that the command chaining for the tape drive in 
question should terminate when a serious error is detected (this will be tricky in the two 
drive case unless we stop both). 

The spec should not imply that error recovery should be attempted in the firmware. The 
complexity of tape error recovery is likely to prohibit the correct treatment of all errors and 
firmware treatment of some errors will still necessitate a complex software error recovery 
system. It seems to me not even close to being worth the microcode space. 

I believe that Pitts Jarvis should be asked to rewrite section 6.1.1, using, and constructing if 
necessary, the standard CSB, IOCB boilerplate, such as now exists in the Pilot Design 
Specification, lliese two thing should each have their own bullets. I do not believe that 



[Iris] < Lynch > Scharmann200978.Memo September 20, 1978 



6.1.1 is either complete or correct as it stands. 

Bravo for section 6.4! However, I believe that the actual numbers should either be cleared 
through Dick Snow or left TBD with the current numbers retained in the document as our 
current thinking. 

I think that this spec is a substantial improvement over our previous controller specs, particularly in 
that it begins to explicitly come to grips with the firmware design problems. 



